【Security Hub修復手順】[EKS.1] EKS クラスターエンドポイントは、パブリックアクセス可能であってはなりません
こんにちは、AWS事業本部の平井です。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか?
当エントリでは、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介します。
本記事の対象コントロール
[EKS.1] EKS クラスターエンドポイントは、パブリックアクセス可能であってはなりません
[EKS.1] EKS cluster endpoints should not be publicly accessible
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容です。 AWS Security Hubの詳細についてはこちらのブログをご覧ください。
コントロールの説明
本コントロールは、EKSクラスターエンドポイントが、パブリックにアクセス可能な設定であれば失敗します。
EKSクラスターエンドポイントとは、KubernetesのAPIサーバーであるkube-apiserverのエンドポイントを指します。
Kubernetesのコントロールプレーンを構成する各コンポーネントに対する要求は全てAPIサーバーを通して行われます。
EKSではkube-apiserverがマネージドで提供され、エンドポイントへのアクセス制限はEKSの設定によって実施します。 そのAPIサーバーエンドポイントでパブリックアクセス(インターネットからアクセス可能)が有効になっている場合に本コントロールは失敗します。
APIサーバーへのアクセスはAWS IAMとKubernetesネイティブのRole Based Access Control(RBAC)との組み合わせで保護されます。本コントロールに準拠することで、これらの設定に不備があった際の防御が可能です。
修正手順
1 対象のリソースの確認方法
- AWSマネージメントコンソールにログインし、AWS 基礎セキュリティのベストプラクティス v1.0.0にて、「EKS.1」を検索します。タイトルを選択します。
- リソースの欄から失敗しているリソースを確認できます。
2 ステークホルダーに確認
ステークホルダー(リソースの作成者や管理している部署などの関係者)に以下を確認します。
- パブリックアクセスをプライベート設定に変更してもよいか
- プライベート設定に変更可能であれば、次の章である「3 パブリックアクセスをプライベート設定に変更」へ進めてください。
設定変更による影響について、十分検証し、EKS上で動かすワークロードに影響ないことを確認下さい。
パブリックアクセスのままにしておく必要がある場合、抑制済み
にステータスを変更しましょう。
パブリックアクセスの場合、可能であればIPアドレス制限を設定を推奨します。
ただし、そのままアクセス制限を設定するとノードグループが作成できない等の問題が発生します。 問題を回避するために、以下のどちらかの方法をとってください。
- ノードグループやFargateからのアクセスを許可する(NAT GatewayのIPアドレス等)
- APIサーバーエンドポイントの「パブリックアクセス」に加えて、「プライベートアクセス」も有効にする
- 詳細は、下記のブログをご参照ください。
どちらかの対策をしてもパブリックアクセス設定が有効であれば、コントロールは失敗しますので、抑制済み
にステータスを変更しましょう。
3 パブリックアクセスをプライベート設定に変更
- 対象のクラスターから[ネットワークワーキング]タブの[Manage endpoint access]をクリックします。
- プライベートに変更し、変更内容を保存します。
- 変更による影響を与える可能性がある警告が表示されます。確認し、問題なければ、[確認]をクリックします。
- ステータスが[アクティブ]後、エンドポイントがプライベートになったことが確認できます。
これで設定は完了です。本コントロールのステータスも解決済みになります。
最後に
今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう!
最後までお読みいただきありがとうございました!どなたかのお役に立てれば幸いです。
以上、平井でした!